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Effective user interface design in software systems is a complex task that often takes 
place without adequate modeling tools . By combining state transition diagrams and the 
storyboard technique of filmmakers, State Transition Storyboards were developed to 
provide a detailed modeling technique for the Goldstone Solar System Radar Data 
Acquisition System human-machine interface. Illustrations are included with a descrip- 
tion of the modeling technique . 


I. Introduction 

User interface design presents a unique set of problems to 
software engineering. After functional specifications have 
determined which parameters are to be available to the opera- 
tor, human -machine interface design becomes basically a prob- 
lem of presentation: having the right information, in the right 
place, at the right time. The presentation is a communication, 
usually complex, carefully sequenced, and often highly visual 
in nature. 

This would seem to imply that the user interface should be 
the easiest part of a software system design to present, to com- 
municate, to previsualize, and to specify. But this has not been 
the case. The design of the interface is often left either to 
last minute improvisation or to full prototyping. The proto- 
typing strategy uses the interface itself as a model. In proto- 


typing, there is no abstraction; instead, there are cycles 
modifications to the full product. 

These approaches fail to consider two techniques th 
have been very useful in software development-step-by-st 
problem decomposition and the development of an exterr 
graphical representation that abstracts important aspects 
the system. Stepwise refinement and top-down design [2] £ 
examples of problem decomposition and data flow diagrai 
[3] are examples of graphical abstractions. 

External representations are valuable because they ma 
design reviews (walk-throughs) possible. Members of 1 
design team can then examine and comment on the desigi 
adding new ideas and directing attention to oversights bef< 
specifications are written and the design is committed to co< 
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In most instances, a diagram is more easily modified than a 
software prototype. The model also forms a record of the 
evolution of the design as problem decomposition proceeds 
from a high-level sketch to a final detailed specification. 

Problem decomposition in the user interface has a differ- 
ent character than successive refinement in structured pro- 
gramming. For example, if the user interface is indeed another 
type of human communication, the problem will decompose 
into the familiar phases of communicating ideas: every inter- 
face would be expected to comprise an introduction or orien- 
tation, a central functional unit with no more than seven 
major phases [4] , and a conclusion or orderly exit. The orien- 
tation might decompose into an introduction screen and a set 
of “help” screens. Then the general content of each screen can 
be sketched and later refined to specify string lengths and 
locations. 


State Transition Storyboards were created to provide the 
Goldstone Solar System Radar (GSSR) Data Acquisition 
software design team with a modeling tool for developing and 
specifying the human-machine interface. The technique com- 
prises two ideas. The Yourdon methodology [3] recommends 
thinking of the user interface as a finite state machine; state 
transition diagrams describe transitions triggered by user 
actions. Software designer Paul Heckel [5] describes the crea- 
tion of a user interface as a communications craft and recom- 
mends the storyboarding technique of filmmaking for describ- 
ing the appearance of the^user interface in a sequential manner. 
Combining these ideas allows a graphical abstraction of the 
interface presentation as it responds to the operator. 


II. Description 

State Transition Storyboards are directed graphs composed 
of nodes, edges, and edge labels. The shape and content of a 


node abstracts the screen presentation. Edges indicate the 
allowable transitions that may take place from that state to 
other states. Edge labels carry two types of information: 
(1) the action that causes a transition is summarized above a 
horizontal line and (2) the steps that effect the transition can 
be listed below the line. These diagrams are visual in nature, 
like much of the user interface itself. Figure 1 is given as an 
illustration. 

Transitions can return immediately to the same state. For 
example, pressing an arrow key on a terminal keyboard might 
cause a “control G” (bell) and a return to the same screen 
state. Symbols or icons can be used to represent states that are 
accessed by many transitions and are therefore graphically 
difficult to connect. As an example, “help” or information 
screens are usually accessible from many states. A small 
labeled screen adjacent to a normal node is used in the man- 
ner of an “off-page connector” to indicate that transitions 
can occur between these states. Figure 2 illustrates these 
situations. 


IN. Summary 

State Transition Storyboards allow a software designer 
to sketch and revise interface design ideas quickly to the 
level of specificity required by the design at that moment. 
Then, given any state as a precondition and a user action or 
system update, the postcondition can be determined immedi- 
ately. Information contained in these diagrams can be easily 
converted to state transition tables in software for accurate 
final prototyping. The GSSR Data Acquisition software team 
is currently exploring extensions to this idea. A draft version 
of the Goldstone Solar System Radar Data Acquisition System 
User Interface plans, using the State Transition Storyboard 
technique, is given in Fig. 3. (The GSSR Data Acquisition 
System is described in TDA Progress Report 42-77 [1 ] .) 
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Fig. 1. Basic diagram elements: 
edges, nodes, and edge labels 



Fig. 2. Special diagramming situations 











Fig. 3. Goldstone Solar System Radar Data Acquisition System User Interface (draft) 
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Fig. 3 (contd) 
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Fig. 3(contd) 































